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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 



Introduction 



The focus of the present document is on NGN OSS architecture, and in particular on the management of IP-based 
services in the NGN network environment. As the lifecycle of services are expected to become shorter and shorter, 
automated OSS processes for service creation and lifecycle management process are needed, as well as tools that 
automatically advertise data about new services to customers. 

For the business, secure e-services is one cornerstone to success in connection with networking (security in connection 
with monitory transactions is a must). In addition, network accessibility and "always-on" are also of tremendous 
importance as a network outage can result in substantial economical losses. Concepts and/or specifications within the 
tariff and billing area may be restructured and changed to meet the requirements of NGN. The ability to offer arbitrary 
service packaging in connection with right pricing will be one area of competitive advantage. 

The task of standardization is to standardize methods and tools that support service development in a consistent way. 
However standardization should not touch areas of competition, which is a very sensitive area for SPs and ISPs. The 
focus regarding service management and support is on Why - leading to requirement statement specifications, on What 
- leading to functional/information modelling (and concrete syntax agnostic) specifications and on How- leading to 
concrete syntax specifications. The present document does not deal with system internal implementation. 
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Scope 



The purpose of the present document is to specify a high level architecture and design principles for the NGN 
Management OSS Architecture Release 1. 

The NGN management Architecture specified in the present document is structured in three views: 

• the Business Requirements view: this presents the business concepts, strategies and requirements, for 
Management on the NGN; 

• the Functional/Information view: this presents the architecture including functions and their relationships and 
the information models and logical interfaces defined for supporting the business requirements. The 
Functional/Information view is the focus of the present document; 

• the Implementation view: this presents the technical components, the technical interfaces and the data models 
defined for supporting the Functional/Information view. 

The security of management aspects are transverse; they cover the three management views: Business Requirements 
view, Functional/Information view and Implementation view. 

The Business Requirements for NGN management are described in the NGN OSS Requirements document 
(TS 188 003 (see bibliography)) and the OSS Services Release 1 document (TS 188 002 (see bibUography)). 

The present document specifies the Functional/Information view of the NGN OSS Architecture for the management of 
the NGN network and services and its specific Security aspects. The NGN OSS Functional/ Information view is based 
on the concepts of TeleManagement Forum's New Generation Operations System and Software (NGOSS) [2] including 
the TMF eTOM, TNA and SID. It should be noted that the Functional and Information views are sometimes described 
separately, however as they are so closely linked, they are considered as a single view for the purposes of NGN 
Management. 

The present document also gives some design principles and guidelines for the Implementation View. A technology 
specific implementation architecture is not specified. However, technology neutral requirements on such an architecture 
are specified. This is to allow the maximum flexibility for NGN equipment vendors, OSS Vendors and Operators in 
packaging functionality as they see fit. 

In the body of the present document the term NGN refers to TISPAN NGN. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Interaction Pattern: a well defined sequence of messages exchanged between a provider and a user 

NOTE: For example the ebXML business transaction activity Request/Confirm. 

IRP Information Service (IS): an Information Service describes the information related to the entities (either network 
resources or support objects) to be managed and the way that the information may be managed for a certain functional 
area (e.g. the Alarm IRP Information Service in the fault management area). Information Services are defined for all 
IRPs (TS 132 101 [3]) 

IRP Solution Set (IRP SS): contains a mapping of the IRP Information Service (IS) to one of several technologies. An 
IS can be mapped to several different Solution Sets. Different technology selections may be made for different IRP 
Information Services. The functionality and information specified in a Solution Set is constrained by the functionality 
and information specified in the associated Information Service (TS 132 101 [3]) 

Network Resource Model (NRM): Information Service describing Information Object Classes representing the 
manageable aspects of network resources, e.g. an RNC or NodeB (TS 132 101 [3]) 

IRP (Integration Reference Point): architectural concept that is described by a set of specifications for definition of a 
certain aspect of the Itf-N, comprising a Requirements specification, an IRP Information Service specification, and one 
or more IRP Solution Set specifications (TS 132 101 [3]) 

Solution Set (SS): mapping of an information model pertaining to an interface to a specific technology. Examples of 
Solution Sets are: 

• 3GPP IRP Solution Sets: see TS 132 101 [3] 

• TMF MTNM Solution Set: see TMF 814 [18] 

NGN OSS Service Interface Group (NGN OSS SIG) (depicted as a dotted line oval): a grouping of NGN OSS 
Service Interfaces that belong together according to a chosen context 

NOTE: NGN OSS Service Interface Groups may be comprised of other NGN OSS Service Interface Groups. 

NGN OSS Operation (NGN OSS Op): a behaviour which is published as a member of an NGN OSS Service Interface 
or an NGN OSS Service Interface Consumer. 

NOTE 1: Each NGN OSS Operation is defined in terms of one specific Interaction Pattern. 

NOTE 2: A behaviour is defined in terms of pre-conditions, post-conditions and exceptions. 

NOTE 3: An NGN OSS Operation can be seen as a capability of the NGN OSS 
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NGN OSS Service (depicted as an ellipse): a profilable aggregation of NGN OSS Service Interfaces and NGN OSS 
Service Interface Consumers, whose aggregate behaviour fulfils a specific business need which can be controlled 
through customizable business policies. 

NOTE: NGN OSS Services may be composed recursively (for details, refer to annex C). 

NGN OSS Service Interface (NGN OSS SI) (depicted as a lollipop): a well defined grouping of related NGN OSS 
Operations and constant data which are necessary to deliver coherent business or system functionality. 

NOTE: The NGN OSS Service Interface is the fundamental unit of standardization. 

NGN OSS Service Interface Consumer (NGN OSS SIC) (depicted as a crescent): a well defined grouping of related 
NGN OSS Operations and constant data which represent the user/consumer of an NGN OSS Service Interface. 

Operations Support System (OSS): generic term for a suite of management functions that enable an enterprise to 
monitor, analyse and manage systems, resources and services 

Process (definition extracted from eXOM [1]): process describes a systematic, sequenced set of functional activities 
that deliver a specified result 

NOTE: In other words, a Process is a sequence of related activities or tasks required to deliver results or outputs. 

Process Element (definition extracted from eTOM [1]): is the highest level of the constructs within the eTOM 
framework, which can be used directly by the enterprise 

NOTE: Process elements are modular for potential reuse and independent update and/or replacement. 

provisioned services: services that are configured through network management applications by the operator 

NOTE: Examples are (IP) VPNs, VLLs, VPLS and other leased line data services and transport services 
("pipes"). These services can be delivered to end-users and whole-sale customers or be part of the 
operator's network infrastructure services to connect to own or ASPs' access networks. 

Service Oriented Architecture (SOA) [19]: software architecture of services, policies, practices and frameworks in 
which components can be reused and repurposed rapidly in order to achieve shared and new functionality. 

NOTE: This enables rapid and economical implementation in response to new requirements thus ensuring that 
services respond to perceived user needs. SOA uses the object-oriented principle of encapsulation in 
which entities are accessible only through interfaces and where those entities are connected by 
well-defined interface agreements or contracts. 

signalled services: services that are initiated by end-users (using SIP or other signalling protocols) from CPE 
equipment/terminals 

NOTE: Examples are voice, video-on-demand, internet access, multi-media calls, etc. 

Third-party Application Services: services that are built using general IT programming environments, make use of 
the available network capabilities and interface with the network capabilities through open interfaces, such as Parlay 

NOTE: These services are the source of the rich service offering that is expected to be possible in the NGN 
environment. These services are also mostly signalled services. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3GPP 3'^'^ Generation Partnership Project 

ABE Aggregate Business Entity 

API Application Programme Interface 

CM Configuration Management 

CMIP Common Management Information Protocol 

CN Core Network 

CORBA Common Object Request Broker Architecture 

CRM Customer Relations Management 

DHCP Dynamic Host Control Protocol 
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EM Element Management 

eTOM enhanced Telecommunications Operations Map 

ETSI European Telecommunications Standards Institute 

FCAPS Fault, Configuration, Accounting, Performance and Security 

IETF Internet Engineering Task Force 

IRP Integration Reference Point 

IS IRP Information Service 

Itf-N Interface N 

ITU-T International Telecommunication Union - Telecommunications sector 

MPCM Market Product and Customer Management 

MTNM Multi Technology Network management 

MTOSI Multi-Technology Operations Systems Interface 

NE Network Elements 

NGN Next Generation Network 

NGOSS^" New Generation Operations Systems and Software - TeleManagement Forum 

NM Network Management 

NRM Network Resource Model 

OMG Object Management Group 

OOAD Object Oriented Analysis and Design 

OSS Operations Support System 

RM Resource Management 

RMI Remote Invocation Method 

SI Service Interface 

SIC Service Interface Consumer 

SID Shared Information/Data model 

SIG Service Interface Group 

SLA Service Level Agreement 

SM Service Management 

SOA Service Oriented Architecture 

SOAD Service Oriented Architecture and Design 

SRM Service Resource Management 

SS Solution Set 

TMF TeleManagement Forum 

TMN ITU-T Telecommunications Management Network 

TNA Technology Neutral Architecture 

TRM Transport Resource Management 

UDDI Universal Description, Discovery and Integration 

UML Unified Modelling Language 

WSDL Web Service Description Language 

XML extended Mark up Language 



4 Introduction to NGN OSS Management views 

The NGN Network Architecture [12] builds on 3GPP IP Multimedia Subsystem (IMS) specifications for part of its 
network architecture and extends them to cover the fixed network requirements. 

The specification of the NGN OSS Architecture should cover the management of this extended network and its 
services. The NGN OSS Architecture shall be defined according to (in line with) the concepts of Service Oriented 
Architecture (SOA) design. 

The NGN management specifications build wherever possible on existing management standards from 3GPP 
(e.g. IRPs), ITU-T and TMF (e.g. MTOSI, MTNM, IPNM). 

This clause introduces the different views on NGN OSS management in terms of business requirements, 
functional/information architecture, implementation views and security aspects. 

TISPAN NGN introduces the following views of NGN management (figure 1): 

• the Business Requirements view: this presents the business concepts, strategies and requirements, for 
Management in the NGN; 



£75/ 



11 



ETSI TS 188 001 V1.1.1 (2005-09) 



• the Functional/Information view: this presents the Service Oriented Architecture [19] including functions and 
their relationships and the information models and logical interfaces defined for supporting the business 
requirements; 

• the Implementation view: this presents the technical components, the technical interfaces and the data models 
defined for supporting the Functional/Information view. 

In this approach, the security of management aspects ai'e transverse (i.e. the security aspects of NGN_OSS 
Management, rather than the Management of Security of the NGN itself, which is an integral part of the 3 views above), 
they cover the three architecture views: Business Requirements, Functional/Information and Implementation. 



Business Requirements view 



Functional / Information view 



Implementation view 
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C/5 



n 




QJ 



D 



Figure 1 : NGN OSS Management Views 

The main purpose of the NGN Management Views is to allow ETSI NGN to document the steps required to progress 
from a set of business needs to the creation of a functional/ information view to logically specify those needs. Then, 
from this Functional/Information View of the Architecture, an Implementation View of the Architecture can be derived 
that takes into account specific realization requirements such as cost, performance, integration or adaptation of legacy 
applications, and technology and other organizational preferences. 

One of the architectural principles behind the architecture for management of Next Generation Networks is that of being 
a Service-Oriented Architecture (SOA). A Service Oriented Architecture (SOA) is a software architecture of services, 
policies, practices and frameworks in which components can be reused and repurposed rapidly in order to achieve 
shared and new functionality. This enables rapid and economical implementation in response to new requirements thus 
ensuring that services respond to perceived user needs [19]. 

SOA uses the object-oriented principle of encapsulation in which entities are accessible only through interfaces and 
where those entities are connected by well-defined interface agreements or contracts. 

The present document concentrates on the Functional/Information Architecture of the OSS required for NGN 
Management. The rest of this clause describes the content of the other NGN management views (Business 
Requirements and Implementation) and the link between the three views. 



5 Business Requirements View 

The business requirements for the NGN network encompass the following paradigms: 

• the Next Generation Network (NGN), as defined by TISPAN (ES 282 001 [12], which distinguishes service 
layer and transport layer. This new network must interact with legacy networks (PSTN, GSM, etc.); 

• new business and operational requirements described in TR 188 004 [20] and specified in TS 188 003 (see 
bibliography), supporting the eTOM Business Process framework (TMF GB921 [14]/ITU-T Recommendation 
M.3050 [1)]). 

The following clause provides an overview of the context of the ETSI TISPAN NGN OSS Architecture. 
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5.1 



Overview of the ETSI TISPAN NGN Architecture 



Figure 2 provides an overview of the NGN Architecture (ES 282 001 [12]). The network subsystems are divided into 
2 layers (Service layer and Transport Layer). The NGN OSS Architecture (clause 6) reflects this division of NGN 
resources into two layers. 
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Figure 2: NGN Architecture components 

The functional entities making up a subsystem may be distributed over network/service provider domains and may thus 
fall into separate management domains. For example, as shown in figure 3 the network attachment subsystem may be 
distributed between a visited and a home network. Service-layer subsystems that support nomadism may also be 
distributed between a visited and a home network. 
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Figure 3: NGN Networl< Distributed Subsystems (ES 282 001) [12] 

The implication of the distribution of the TISPAN NGN Architecture is that the NGN OSS Architecture needs to be 
distributed following the same principles. 
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5.2 NGN Business and Operational requirements 

Business and operational requirements for NGN management are specified within different sources, amongst which: 

• OSS Vision, TR 188 004 [20]; 

• eTOM Business Process Framework (TMF GB921 series [14]; ITU-T Recommendation M.3050 series [1]); 

• OSS Requirements and Priorities, TS 188 003 (see bibliography); 

• OSS Services Release 1, TS 188 002 (see bibliography). 

5.2.1 NGN OSS Vision 

The "OSS Vision" document presents business, regulatory and operational requirements, utilizing the eTOM as 
reference business process framework, and referring to the TeleManagement Forum NGOSS (New Generation 
Operation Systems and Software) program as reference industry approach for development of OSSs. 

5.2.2 eTOIVI Business Process Framework 

eTOM is a business process model or framework that has the objective of describing and classifying the business 
processes required for a Service Provider; it analyzes the processes to different levels of detail according to their 
significance and priority for the business. 

eTOM uses hierarchical decomposition to structure the business processes according to which all of the processes of the 
enterprise are successively decomposed. Process elements are formalized by means of a name, a description, 
inputs/outputs, etc. 

The eTOM supports two different perspectives on the grouping of the detailed process elements: 

• horizontal process groupings, in which process elements are grouped according to reference accomplished 
functionalities (e.g. Market and Product and Customer management. Service management, etc.); 

• vertical process groupings, in which process elements are grouped within End-To-End processes 
(e.g. Fulfilment, Assurance, etc.) accomplished by the Service Provider enterprise. 

The eTOM Business Process Framework is defined as generically as possible, so that it is independent of organization, 
technology and service. However it is not a Service Provider business model. 
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Figure 4: eTOM Business Process Framework (TIWF GB921 [14], ITU-T Recommendation l\/l.3050.1 [1]) 

Since the eTOM framework provides a description of Service Provider processes, this framework provides implicit 
business requirements for the specification of the NGN OSS Architecture. 

The NGN OSS Architecture specified within the present document comphes with the above requirements. 



6 Functional/Information View 

The Functional/Information Architecture view describes the components, functions and information needed to fulfil the 
Business Requirements in order to provide the NGN OSS Services as defined in TS 188 002 (see bibliography). 

6.1 Principles underlying the View 

The NGN OSS Functional/Information View builds on the following principles: 

• The OASIS Service Oriented Architecture (SO A) [19]. 

NOTE: This does not rule out the import of non-SOA-based or "legacy" standards from 3GPP, TMF or other 
organizations. 

• The 3GPP Integration Reference Point (IRP) [3] to [1 1] concept. 

• The TMF NGOSS Technology Neutral Architecture TMF 053 [2] . 

• Applicable concepts of ITU-T. 

• Applicable concepts of TMF MTNM/MTOSI/IPNM. 

The fundamental SOA concepts that are adopted within the NGN OSS Architecture are: 

• operations: they represent single logical units of behaviour. They have a specific, structured interface, and 
return structured responses using a particular interaction pattern; 
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• service interfaces: logical groupings of operations. 

Using the above ideas and principles, the rest of this clause introduces the basic concepts and entities used in the 
description of the SOA-based NGN OSS Functional/Information View. The proposed formal relationship amongst these 
entities is established in an Architecture Meta-model presented in the informative annex C. 

The NGN OSS Architecture concepts and entities are defined in a way that enables the re-use of/ mapping to existing 
management interface standards from e.g. 3GPP, ITU-T and TMF. 

Details on the correspondence of these concepts to similar concepts used in 3GPP are given in annex C. The 
formalization of the mapping of these concepts to 3GPP concepts and the correspondence or mapping to similar 
concepts of ITU-T and TMF are for further study in Version 2. This may lead to further adaptations of the Metamodel 
as required. 

6.2 Methodology for the identification of NGN OSS 
Functional/Information View entities 

Service orientation is an approach to defining distributed, interface-oriented systems that deliver functionality as 
services. These services are accessed through the interfaces they expose. 

The objective of the definition of the NGN OSS Functional/Information View is the identification of the logical service 
interfaces to be provided by components of an NGN OSS system. Then such parts can be assembled into an NGN OSS 
system by using their interfaces in a way that supports a particular Service Providers' business processes. 

The logical service interfaces of the NGN OSS service-oriented architecture are the primary focus of standardization. 

In order to identify the NGN OSS Service Interfaces of the NGN OSS Architecture that need to be standardized, the 
management functions expressed in the Business Requirements view (clause 5.2) need to be mapped to the NGN OSS 
Functional/Information View. 

For a given set of known Service Interfaces, a Service Interface Group can be used to associate such Service Interfaces 
into different groups on the basis of a criterion chosen to fulfil a certain need, e.g. common functionality, a selling 
package, a directory organization, alphabetical order, etc. Thus the NGN OSS Service Interface Group can be the means 
through which NGN OSS Service Interfaces will be identified and grouped. 

Initially, for the NGN OSS Functional/Information View under definition, the NGN OSS Service Interfaces are not yet 
formalized and first need to be identified. However, as the target of the NGN OSS Functional/Information View is to 
support Service Providers' business processes on a flexible way, the eTOM Business Process Framework [14] has been 
chosen as the guiding criterion to group NGN OSS Service Interfaces. 

• At the top level, the NGN OSS Service Interface Groups are defined to support the eTOM Level 1 functional 
process groupings. 

• Then, each of these top level NGN OSS Service Interface Groups can be further refined into smaller NGN 
OSS Service Interface Groups in order to support Level 2, Level 3, Level 4 etc. eTOM processes. 

• This refinement of NGN OSS Service Interface Groups can thus be utilised as a practical method for the 
identification of individual NGN OSS Service Interfaces. 

Examples of the use of the concept of NGN OSS Service Interface Group are contained in annex B. 

6.3 Entities composing the NGN OSS View 

This clause introduces the definitions of the different entities used to describe the NGN OSS Functional/Information 
View and provides their formal definition with additional explanations. 

6.3.1 Overview 

The NGN OSS Service and the NGN OSS Service Interface are the main basic entities used in the description of the 
NGN OSS View. An NGN OSS Service Interface provides access to functionality for managing the NGN in a way that 
supports the eTOM operational processes. 
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NGN OSS Service Interfaces are the target of standardization and shall be specified as well-defined sets of related 
behaviours that together deliver necessary functionality to be provided by an NGN OSS. 

Each behaviour is specified as an operation with a well-defined name, data, and pre- and post-conditions. 

NGN OSS Service Interfaces and Service Interface Consumers are grouped into NGN OSS Services. 

For a given NGN OSS Service, NGN OSS Service Interfaces and Service Interface Consumers may be defined as 
mandatory or as optional. The NGN OSS Service can be profiled: a profile of an NGN OSS Service indicates which of 
its Service Interfaces and Service Interface Consumers are present in a given specification used in the description of a 
possible realization of an NGN OSS system. All NGN OSS Operations within an NGN OSS Service Interface/Service 
Interface Consumer must be provided if the NGN OSS Service Interface/Service Interface Consumer is present in the 
specification, i.e. individual operations cannot be profiled. 

The basic NGN OSS Architecture principles require that NGN OSS Service Interfaces are made publicly available for 
use by NGN OSS Service Interface Consumers. 

Following the above introduction, the NGN OSS Functional/Information View is described in terms of the entities 
explained below. 

The proposed correspondence of these entities with 3GPP concepts can be found in annex C. 

6.3.2 NGN OSS Service Interface 

NGN OSS Service Interface (NGN OSS SI) (graphically depicted as a lollipop): a well defined grouping of related 
NGN OSS Operations and constant data which are necessary to deliver coherent business or system functionality. 

The NGN OSS Service Interface is: 

• The fundamental unit of standardization. 

• An aggregation of functionality required for managing some coherent aspect of the NGN network or services. 
This functionality is provided through a set of related behaviour/functionality and is made publicly available 
for use by consumers of this service interface. An example is an Alarm Reporting service interface that offers 
the functionality supporting the NGN OSS Operations 'getAlarmList' and 'acknowledgeAlarms'. 



• 



Comprised of a set of NGN OSS Operations which must be all present. 
• Equivalent to the SOA service interface concept. 

6.3.3 NGN OSS Service Interface Consumer 

NGN OSS Service Interface Consumer (NGN OSS SIC) (graphically depicted as a crescent): a well defined grouping 
of related NGN OSS Operations and constant data which represent the user/consumer of an NGN OSS Service 
Interface. 

NGN OSS Service Interface Consumer is: 



• 



• 



The means through which an NGN OSS Service indicates how/if it uses an NGN OSS Services Interface 
published by another NGN OSS Service. 

A consumer of those NGN OSS Service Interfaces that offer the functionality that its associated NGN OSS 
Service needs to realize its own NGN OSS Service Interfaces. 



SOA principles require that relationships between NGN OSS Service Interfaces and NGN OSS Service Interface 
Consumers can be established dynamically at run time to perform activities in support of business requirements. 
However, for early deployment reasons, this relationship may initially also be established manually by Systems 
Administration people (in the NGOSS Operations Viewpoint) rather than by the services themselves at run time. This 
may also be needed for dimensioning, planning and performance reasons. 
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6.3.4 NGN OSS Service 

NGN OSS Service: a profilable aggregation of NGN OSS Service Interfaces and NGN OSS Service Interface 
Consumers, whose aggregate behaviour fulfils a specific business need which can be controlled through customizable 
business policies. 

The NGN OSS Services are: 

• Composed recursively (for details, refer to annex C). 

• Organized into one or more NGN OSS Service Interfaces each of which contains a set of NGN OSS 
Operations. 

• Used together in orchestrated or choreographed assemblies to deliver specified service/network provider 
business results according to those business processes that are necessary to manage the NGN. 

• Packaged for implementation purposes. 

NOTE: The association of service interfaces with services is out of the scope of standardization. 

An NGN OSS Service may capture aggregate behaviour across several NGN OSS Service Interfaces. For example, an 
NGN OSS Service - "Manage Telephone Numbers and Telephone Number Ranges" - may need to model the state and 
policies associated with individual Telephone Numbers and Telephone Number Ranges. 

A Manage Telephone Number NGN OSS Service may have a number of service interfaces: e.g. "Assign Telephone 
Number ", Check Telephone Number Status", and "Release Telephone Number". 

Initially the use case definition for "Assign Telephone Number" might define either the response that the Telephone 
Number is free and assigned to the requesting party, or respond that it is not available. When Telephone Numbers are 
released they may enter a quarantined state and requests for re-assignment may be refused until the quarantine interval 
has expired. The existence of a quarantined state may not be visible to this "Assign Telephone Number service 
interface, only the free and not available states. 

Different operators may set different quarantine periods to one another, and different periods for different types of 
numbers. 

If subsequently there is a need to introduce the concept of Number Portability it is necessary to introduce a new number 
portability NGN OSS Service Interface to manage additional sub-states of telephone numbers whilst they are being 
ported e.g. Marked for porting. Porting, Ported. These states do not need to be made available to the previously defined 
Interfaces. 

In both these cases Aggregate Behaviour i.e. the state and policies of telephone numbers, are best captured in the 
definition of the NGN OSS Service, not the NGN OSS Service Interfaces. 

It should be noted that binding state and policies to the NGN OSS Service leads to clear and more complete 
specification than simply specify the Interfaces" states, and also allows for the natural evolution of related Interfaces 
and Services. 



6.3.5 NGN OSS Operation 



NGN OSS Operation (NGN OSS Op): a behaviour which is published as a member of an NGN OSS Service Interface 
or an NGN OSS Service Interface Consumer. 

NGN OSS Operation(s): 

Is bound to a specific NGN OSS Service Interface or NGN OSS Service Interface Consumer. 

Represents a published behaviour of the NGN OSS Service exposing this NGN OSS Service Interface. 



• 



• 



• 



Maybe defined using NGN OSS Operations that are published as part of NGN OSS Service Interfaces of other 
NGN OSS Services. 
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• Is a single logical unit of behaviour. This behaviour is defined in terms of pre-conditions, post-conditions, and 
exceptions, and further policy artefacts, in which case the NGN OSS Operation is called contract-defined. An 
example of an NGN OSS Operation is the 'getAlarmList' operation as specified in the 3GPP Alarm IRP 
Information Service document (TS 132 111-2) [15]. 

• Are defined using "Message Exchange Patterns" (such as synchronous or asynchronous Request/ Response/ 
Notification) as defined, for example, by TMF NGOSS Contracts, the design pattern TMF MTOSI 
communication styles and patterns, and W3C WSDL. Each NGN OSS Operation is defined in terms of one 
specific Interaction Pattern (e.g. SRR, SIT, SFB, ARR, ABR, AFB in case of TMF MTOSI), which is a well 
defined sequence of messages exchanged between a provider and a user, such as the ebXML business 
transaction activity RequestConfirm. 

NOTE: Correspondence with 3GPP IRP can be found in annex E. 



6.3.6 NGN OSS Service Interface Group 



NGN OSS Service Interface Group (NGN OSS SIG): a grouping of NGN OSS Service Interfaces that belong together 
according to a given logic or context. 

NGN OSS Service Interface Group(s): 

• Are basically collections of NGN OSS Services Interfaces that have similar characteristics or business 
objectives. Possible examples of such collections may be Utility Services (defined by NGOSS as OSS 
Framework Services), or groups of OSS Business Services needed to support business objectives such as 
Customer Relationship Management (CRM). 

• May be a member of several NGN OSS Service Interface Groups. For example, the operations of the 
"Customer Profile Management" NGN OSS Service Interface could belong to both a Provisioning and a 
Billing Management Service Interface Group. 

• Can be comprised recursively of NGN OSS Services and/or other NGN OSS Service Interface Groups. 

• Can be seen as a subset of the capabilities or a management functions of the NGN OSS. 

6.4 The NGN OSS Function/Information View Reference Model 

Using the entities introduced in the previous clause, the NGN OSS Functional/Information View Reference Model 
(figure 5) can be presented as a collection of NGN OSS Services which provide groups of NGN OSS Operations that 
are exposed as NGN OSS Service Interfaces and that use the NGN OSS Service Interfaces of other NFN OSS Services 
through NGN OSS Service Interface Consumers. 

The binding between NGN OSS Service Interfaces and NGN OSS Service Interface Consumers is not described in the 
Functional/Information View. 
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Figure 5: NGN OSS Functional/Information View Reference IVIodel 

NGN OSS Service Interface Groups can be used to create different views on the NGN OSS Service Interfaces 
according to different criteria. For example, a criterion can be "alphabetical order" for use by Marketing tools or 
Product offer management tools, or a domain oriented grouping for use by different operators. 
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Figure 6: NGN OSS Service Interface Groups: example 

Clause 10 identifies the NGN OSS Service Interface Groups and related NGN OSS Service Interfaces required for 
defining the NGN OSS Functional/Information View. 
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7 Implementation View 



Essentially the NGN OSS Implementation view is the transformation of the Functional and Information View into a 
Implementation view as shown in figure 1 . Note that constraints, and requirements, are placed on the Implementation 
View covering cost, legacy, performance and preferences. The most important preferences are the choice of software or 
protocol platforms for realization. The binding between NGN OSS Service Interfaces and NGN OSS Service Interface 
Consumers is realised in the Implementation View. 

The target Implementation view: 

• uses practical and available SOA technology implementations, such as, but not limited to, OSS/J Remote 
Method Invocation (RMI) and Java Messaging Services (JMS), Web Services using XML/SOAP AVDSL, 
MTOSI JMS vl and MTOSI v2 HTTP/S (which is SOA WSDL based); 

• re-uses 3GPP IRP Solution Sets as needed; 

• re-uses TMF Solution Sets and ITU-T interface specification as needed; 

• adds NGN specific management specification Solutions Sets as needed. 

7.1 Introduction to SOA implementation 

A service oriented architecture (SOA) is a software architecture involving loosely coupled, location independent 
services generally using the so-called "find-bind-execute" paradigm for the communication between SOA service 
providers, SOA service users and a SOA service registry. Any given service may assume a client or a server role with 
respect to another service, depending on situation. An essential characteristic of an SOA is that it provides published 
contract-based, platform and technology neutral service interfaces. This means that the interface of a service is 
independent of its implementation. In practice, interfaces are defined using ubiquitous IT standards such as XML, 
HTTP, SOAP, and WDSL. 

Major goals of an SOA in comparison with other software architectures used in the past are to enable: 

• faster adaptation of software to changing business needs; 

• cost reduction in the integration of new services, as well as in the maintenance of existing services. 

Today, an SOA is a key to the development and deployment of heterogeneous, network addressable software 
components. Web Services currently represent the most well known implementation of an SOA although Java and 
proprietary Enterprise Bus systems follow similar principles. 

7.2 Implications of SOA implementation 

Currently TMF NGOSS TNA (TMF 053D) is the only known source of metamodels to specify SOAs [2]. 

NOTE: In the present document the definition of SOA is taken from OASIS [19]. 

NGOSS is based upon the use of the eTOM, SID, and NGOSS platform specifications including the key concept of an 
NGOSS Contract to specify the services exposed by NGOSS Components. The critical features of a SOA are captured 
in the NGOSS principles: 

• Common Communications Vehicle - Reliable distributed communications infrastructure e.g. Software bus 
integrating NGOSS components and workflow; 

• externalize Process Control -Separation of End to End Business Process Workflow from NGOSS Component 
functionality; 

• Shared Information Data Model - NGOSS Component uses /implements a defined part of the SID model; 

• Business Aware NGOSS Components - where component services/functionality are defined by NGOSS 
Contracts; 
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• contract trading and registration using NGOSS Framework Components (covering things like directories, 
transactions, HMI, security, etc.)- 

NGOSS has a layering of services, as shown in figure 7. 





Policy 








Business Process 








OSS Applications 












OSS Framework Services 












Basic Framework Services 












Basic mechanisms 

















Figure 7: NGOSS layering of services (TIUIF 053 [2]) 

The Functional/ Information architecture focuses on providing the structure of the OSS Applications and the OSS 
Framework Services such as Logging. 

The Basic Framework Services and Basic Mechanisms are provided by the platform used to realize the Architecture. 
The Implementation View is most concerned with setting constraints and making choices in the way that these Basic 
Framework Services and Basic Mechanisms are realized. 

A important NGOSS Framework Service is the Registration Service and the repository to allow component to register 
and discover other component (TMF 053 p. 49 figure 16 [2]). In some technologies such as Web Services these 
framework services are supported by entities called UDDI Registries e.g. Universal Description, Discovery and 
Integi-ation (UDDI). 

7.3 Role of Registry/Directories in SOA Implementation 

This latter principle has very considerable impact on the architecture as it means that components must register 
themselves and that clients of these components use a "fmd-bind-execute model". This means that the interactions 
between components are established dynamically at run time unlike the traditional concept of TMN architectures where 
interactions are defined statically at design time in the form of reference points. 

7.4 SOA Registry/Directory Organization 

An important aspect of a SOA is that a Directory is needed to support the trading and registration services to support the 
"find" operation. These directories, an example being the UDDI directories used for Web Services, need to have a 
taxonomy or classification schema for organizing the registered web services. 

In this Functional/Informational Architecture the primary classification scheme is based on the TMF eTOM 
decomposition hierarchy. Secondary Classification schemes could include the TMF SID Aggregate Business Entity 
(ABE) hierarchy, or the forthcoming TMF Application Map. 
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8 Security of Management 



The security of management aspects are transverse, they cover the three architecture views: Business Requirements, 
Functional/Information Architecture and Implementation. 

Detailed Security architecture implementation is for further study. 



9 Linking Business, Functional/Information and 

Implementation Views 

The NGN OSS Business, Functional/Information and Implementation views are partly described in different and often 
multiple standards documents today: 

• business requirement are mostly specified in the TMF eTOM; 

• functional/information views and related requirements are specified by the TMF NGOSS (Technology Neutral 
Architecture and SID model) and TMF MTOSI/MTNM/IPNM, 3GPP and ITU-T documents; 

• implementation views are also given by the TMF NGOSS program and MTNM/MTOSI specifications, 3GPP 
and ITU-T. Moreover, several implementation related fora, such as OMG, OSS/J, OASIS and W3C also 
specify "semi-standard" implementation views. 

9.1 Assumptions for linkage 

For ETSI TISPAN, the following assumptions hold: 

• eTOM business requirements are expected to be valid for the NGN OSS, even if today's eTOM may need 
further elaboration of some business processes to cover NGN; 

• 3GPP management requirements, functional/information architecture and implementation views are a prime 
resource for the ETSI NGN. 3GPP management specifications cover today the mobile network management 
and could be extended to cover NGN management. They also cover the basics of the next generation service 
resource management support around subscriber, and subscription management; 

• TMF MTNM specifications may be used to cover today the network resource management of fixed edge/core, 
transport and access networks. Network resource management for VoIP as the next generation service is 
covered by TMF IPNM specifications. Both are of prime importance in the definition of the ETSI 
TISPAN_OSS for NGN management; 

• ITU-T management specifications cover the still valid basic management FCAPS concepts. It is assumed that 
reference point definitions will evolve to support the more flexible integration requirements of the NGN OSS; 

• fixed/mobile convergence, or rather the "any access to any service, any time, any where" requirements, imply 
that the NGN OSS implementations are based on common Services and Transport resources models for both 
fixed and mobile technologies. 

The ETSI TISPAN approach needs to take into account all the above mentioned points, and also has to recognize the 
fact that the next generation software architecture will be a Service Oriented Architecture (SOA), e.g. WebServices 
based. 

9.2 Route to convergence 

There is a need to converge TMF NGOSS, ITU-T, 3GPP, and TMF MTNM and IPNM specifications. 

The proposed approach is that ETSI NGN OSS focuses on the definition of service-oriented, technology independent 
management interfaces for the OSS which is sufficiently decoupled from individual 3GPP, MTNM/IPNM and ITU-T 
network resource management specifications to allow for an abstract view towards the managed networks. 
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ETSI TISPAN introduces concepts for use in the definition of the ETSI NGN OSS Functional/ Information Architecture 
which allow to englobe related concepts of these other management specifications, in particular the 3GPP Integration 
Reference Point (IRP) concept, so that maximal re-use of existing specifications is possible. 

These concepts offer on the one hand a functional modularity required to support the operational processes on the 
functional NGN OSS architecture and NGN network. On the other hand, they provide the flexibility required by the 
Service Oriented Architecture and can be considered as a first step to e.g. WebServices support. The ETSI_TISPAN 
introduced concepts also enable stepwise evolution from existing implementations by their openness to new interface 
technologies while enabling re-use of existing Requirements and Information Model specifications. 

Using the introduced concepts, the resulting ETSI TISPAN specifications will be documented as follows: 

• The link with the eTOM business aspects is documented in the "NGN OSS Requirements" document that 
provides the grouping of these requirements in terms of NGN OSS Service Interface Groups. 

• The link between the Requirements view and NGN OSS Functional/ Information Architecture view will be 
given by means of a mapping of the requirements into NGN OSS Service Interface Groups which group NGN 
OSS Service Interfaces. After sufficient decomposition of NGN OSS Service Interface Groups, this will result 
in a set of NGN OSS Service Interfaces to be standardized. 

• For each NGN OSS Service Interface, the link with a particular Implementation View will be given by 
mapping to a Solution Set (refer to clause 7). This step will be further described in Version 2 of the present 
document. 

The following clause describe the NGN OSS Functions Sets and their mapping onto entities of the NGN OSS 
Functional/Information Architecture. 



10 NGN OSS Functional/Information View and Service 
Interface Groups 

The NGN OSS Functional/Information Architecture covers the management of both fixed and mobile networks and has 
to handle a set of new NGN related aspects such as network capabilities and an all-IP multi-media service environment. 

TISPAN NGN inherits as much as possible from the 3GPP IMS architecture. 

Working top down, this clause creates an NGN OSS Functional View by mapping the NGN OSS Requirements onto 
main NGN OSS Service Interface Groups. This is the first step required in the identification of the NGN OSS Service 
Interfaces which will then be used in the definition of the NGN OSS Functional/ Information Architecture definition. 

Examples related to NGN OSS Service Interface Groups are found in annex B. 

10.1 IVIapping of NGN OSS Requirements to Service Interface 
Groups 

Due to the complexity of both the business and the support systems there is a need for a framework that can be used 
when systems are developed within the scope of the architecture. For that purpose a NGN OSS reference model is 
defined in this clause. 

The main purpose of this model is to help business and development projects to make clear distinctions between 
different management areas in order to utilize a stable and cost-effective management environment. NGN OSS 
architecture consists of Service Interface Groups, or groupings of Service Interface Groups. 

At the highest level, the NGN OSS Functional/Information view supports three main NGN OSS Service Interface 
Groups grouping respectively the NGN OSS Service Interfaces required for managing: 



• 



customer facing aspects of the OSS, e.g. the Market, Product and Customer Management Service Interface 
Group; 

services on the NGN networks, e.g. the Service Management Service Interface Group; 
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• resources of the NGN network, e.g. the Resource Management Service Interface Group. 
Figure 8 depicts the NGN OSS Functional/Information view in terms of NGN OSS Service Interface Groups. 
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Figure 8: NGN OSS Functional View in terms of eTOM based Service Interface Groups 

The motive for this NGN OSS Functional/Information View is that technology and business must be able to develop 
independently from each other. The technology independent Market Product and Customer Service Interface Groups 
and Service Management Service Interface Groups guarantee this. 

Within the NGN OSS Functional/Information View, there is a Service Interface Group, named Basic Framework 
Services Service Interface Group, which provides common services (e.g. security, directory, etc.) supporting the other 
Service Interface Groups. 

NOTE: The security services provided within the Basic Framework Services Service Interface Group are used for 
the management of security of the NGN services. 

The NGN OSS Functional/Information View encompasses management functionality of NGN managed resources, that 
are part of the NGN Transport layer or the NGN Service layer. Such management functionality can be either directly 
exposed by the NGN (Service or Transport) Resources located within the actual NGN network or proxied (Managed 
Services Resource / Managed Transport Resource Service Interface Groups). 

The Supplier/Partner Management Service Interface Group included in the NGN OSS Functional/Information View is 
for further study. 

10.2 Market, Product and Customer Management (MPCM) 
Service Interface Group 

The Market, Product and Customer Management Service Interface Group (MPCM) is the customer facing Service 
Interface Group in the NGN OSS Functional View. It is mainly responsible for supporting the development, 
management and improvement of the relationship with the Customer and for the development, management and 
retirement of Products. 
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The management functions which compose the MPCM Service Interface Group will be specified in further releases of 
the present document. It is suggested to refer to the eTOM framework (TMF GB921 series [14] - ITU-T 
Recommendation M.3050 series [1]) and to the SID (Shared Information/Data Model) model (TMF GB922 series [16]), 
as first reference sources for collection of reference information in order to specify the above mentioned management 
functions. 

Some examples (not to be intended as an exhaustive list) of management functions of the MPCM Service Interface 
Group may be: 

• management of instances of Products during their whole lifecycle; 

• management of the interaction with customers through a well-defmed business interface; 

• administration and management of functionality that uses information from the Service Management Service 
Interface Group (such as trouble ticket handling, collection and processing of accounting data on a 
product- and/or customer level); 

• definition of the product itself from a marketing and commercial perspective (i.e. the characteristics of the 
product, how to bill, to whom it is addressed, geographical covering of the offer, bundling of services, etc.). 

In terms of comparison with the eTOM framework, the MPCM Service Interface Group can be mapped with the eTOM 
Marketing and Offer Management and Customer Relationship Management process groupings. 
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Figure 9: Marl<et Product and Customer Management Service Interface Group compared with eTOM 

10.3 Service Management (SM) Service Interface Group 

The Service Management (SM) Service Interface Group includes those management functions dealing with Service 
development, management and operations. All management functions within the SM Service Interface Group will be 
"resource/technology independent" and will not have any knowledge of the underlying resources involved in the 
provisioning of services to the customers: no information about transport or service platforms are available in the SM 
Service Interface Group. 

The exhaustive set of management functions which compose the SM Service Interface Group will be specified in 
further releases of the present document. It is suggested to refer to the eTOM framework (TMF GB921 series [14] - 
ITU-T Recommendation M.3050 series [1]) and to the SID (Shared Information/Data Model) model (TMF GB922 
series [16]), as first reference sources for collection of reference information in order to specify the above-mentioned 
management functions. 

Some examples (not to be intended as an exhaustive list) are given below of management functions of the SM Service 
Interface Group related to delivery of service capability, service configuration, service problem management, service 
quality analysis and management, service rating, etc. according to customer expectations. 
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Typical management tasks that would be performed within the SM function may be: 

• the management of the service from an end-to-end perspective (service configuration, service re-routing, 
service activation, service quality assurance, etc.); 

• the management of service profiles (each service profile expresses the network and service resources 
requirements needed to activate the service) and the management of the association of actual subscribers to the 
set of profiles corresponding to this subscribers service contract; 

• the supervision and proactive management of services to guarantee contractual SLA(s); 

• the management of usage records for provision of data to the MPCM Service Interface Group in cases of not 
respected SLA(s); 

• etc. 

In terms of comparison with the eTOM framework, the SM Service Interface Group can be mapped with the eTOM 
Service Development and Management and Service Management Operations process groupings. 
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Figure 10: Service IVIanagement Service Interface Group compared with eTOIVI 

The SM Service Interface Group relies on the Resource Management (RM) Service Interface Group to map its service 
oriented view and information to the required resources. 

10.4 Resource Management (RM) Service Interface Group 

While the Service Management (SM) Service Interface Group has the responsibility for managing the service lifecycle 
and the delivery and assurance of service instances independently from the type of underlying resources, the Resource 
Management (RM) Service Interface Group is responsible for the management of the logical and physical service and 
transport infrastructure. 

With respect to the management of the resources of the non-NGN networks, changes due to the introduction of NGN 
include the need to: 

• manage resources linked to services (application and content servers, etc.); 

• manage resources linked to new network capabilities (localization, presence, nomadism, etc.); 

• support self - and home network management; 

• support the combined management of fixed and mobile transport network resources. 
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The Resource Management (RM) Service Interface Group enables the mapping of service-oriented information used by 
the Service Management (SM) Service Interface Group into resource/technology dependent information. 

In terms of comparison with the eTOM framework, the RM Service Interface Group can be mapped with the eTOM 
Resource Development and Management and Resource Management and Operations process groupings. 
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Figure 11 : Resource IVIanagement Service Interface Group compared with eTOM 

The RM Service Interface Group is composed of two Service Interface Groups: 

• the Service Resource Management (SRM) Service Interface Group; 

• the Transport Resource Management (TRM) Service Interface Group. 

The SRM Service Interface Group corresponds to a new set of resource management features related to support the 
service layer of the NGN, such as the management of applications, application data, users, user data, terminal 
equipment, etc. 

The TRM Service Interface Group corresponds to the traditional transport management functions, with enhancements to 
support the transport layer of the NGN, such as end-to-end IP connectivity and QoS management, etc. 

In the following, an example of the interactions between the SM Service Interface Group and the RM Service Interface 
Group is given. The provisioning of a given service to an end-user will result in the following actions: 

• the creation in the SM Service Interface Group of a new service instance that will associate the results of the 
allocation of the required service resources and transport resources (connectivity) to this service instance by 
the RM Service Interface Group; 

• an interaction with the TRM Service Interface Group: 

1 ) for checking availability of required network resources; 

2) for the end-to-end/cross-application configuration of required network resources; 

3) for configuring this end-users' access line according to the technical requirements corresponding to the 
service contract. 

• an interaction with the SRM Service Interface Group: 

4) for creating all user related data the relevant network databases in case of a new user; 

5) for creating all service related data for this user in the relevant network databases; 

6) for triggering/checking the configuration of the CPE equipment. 
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1 0.4.1 Service Resource Management (SRM) Service Interface Group 

While the Service Management (SM) Service Interface Group has the responsibility for managing the service lifecycle 
and the delivery and assurance of service instances, the Service Resource Management (SRM) Service Interface Group 
is responsible for the management of the implementation and logical infrastructure resources required to enable the 

services. 

This service infrastructure includes the data/information required to enable the NGN services with: 

• associated mechanisms used by the services to access the data; 

• the management of the contained data. 

The Service Resource Management (SRM) Service Interface Group includes, but is not limited to, the following 
functions: 

• the mapping of the SM Service Interface Group requirements into service profiles and data interpretable by the 
underlying EMS/NMS and network nodes; 

• the management of the application software and application data in the network, including introduction, 
upgrade, inventory, distribution, application technologies, open application interfaces and associated security 
mechanisms; 

• the management of the end-user actions on his/her service profile: access by the end-user to his/her profile, the 
management of the impact on OSS systems following profile changes made by the end-user; 

• the management of the aspects related to Service Capabilities, such as Presence, Location, Nomadism, and 
their impact on active services from the user perspective; 

• the management of the aspects related to Network Capabilities, such as Billing, Routing, etc.; 

• the management and mechanisms to support subscription to services and the management of the subscription 
by the end-user (self management); 

• the management of the subscriber data and user profile database and its content; 

• the collection of service delivery SLA data (data to calculate the time to deliver a service to a user after 
subscription) in order to guarantee that services are delivered with the requested characteristics; 

• the collection of service performance data and its analysis to enable input to service resource planning 
functions; 

• the management of the service required software and configuration on CPE; 

• the management of the system allowing for CPE management; 

• the management of the pre - testing of the service; 

• the management of the application redundancy policy; 

• the management of the re-dimensioning of the infrastructure in case the service needs to be extended; 

• the management of the collection of application performance data. 

An example that illustrates the SRM Service Interface Group as well as the possible information models and solution 
set is given in annex A. 

1 0.4.2 Transport Resource Management (TRM) Service Interface Group 

The Transport Resource Management (TRM) Service Interface Group is responsible for the realization of the required 
connectivity and for the configuration of other provisioned service related aspects in the NGN. This includes functions 
such as selection of network technologies, routing, network resource management, inventories, etc. 
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Transport Resource Management Functions handle the management of the transport layer, e.g. IP/MPLS tunnels, 
multi-point VPNs, VLLs and transport services, etc. 

The Transport Resource Management Service Interface Group relies on existing management functions, and defines 
additional NGN management functions for handling the end-to-end aspects of implementing services on the network, 
such as: 

• the management of the connectivity aspects related to the provisioning of resources related to access lines; 

• the management of QoS mechanisms and mappings at inter-network borders, security and NAT/firewall 
configuration, signalling network configuration. 

The Transport Resource Management (TRM) Service Interface Group includes, but is not limited to, the following 
functions: 

network to service alarm correlation; 

network access point configuration based on Service Profiles; 

enabling end-to-end IP-based connectivity configuration; 

enabling end-to-end IP -based connectivity assurance; 

VoIP Infrastructure Management (trunking, routing, etc.); 

Network Quality Management; 

collecting service related network performance data on the network to enable service planning. 

An example that illustrates the TRM Service Interface Group as well as the possible information models and solution 
set is given in annex A. 

10.5 Managed NGN Resources Service Interface Group 

Managed Resource Service Interface Groups group the functions provided by Managed Elements present in the network 
and used by the Resource Management Service Interface Group. Their identification is for further study. 



1 1 NGN OSS Service Interfaces 

1 1 .1 Introduction to TISPAN NGN OSS Service Interfaces 

The previous clause has identified several NGN OSS Service Interface Groups, each grouping a number of NGN OSS 
Service Interfaces. The next step, for each NGN OSS Service Interface Group, identifies and further decomposes these 
NGN OSS Service Interface Groups in order to determine those NGN OSS Service Interfaces that need to be 
standardized. 

NGN OSS Service Interfaces will be defined whenever possible through re-use or enriching of existing management 
standards, and may concern only new specifications specifically for NGN OSS requirements in the case that no existing 
management standard is available yet. 

The present clause focuses on identifying the NGN OSS Service Interfaces that: 

• Map onto existing management specifications: in this case the present document shall only contain references 
to them and explain in an annex how this mapping is achieved. This will concern fixed network management 
standards (e.g. TMF MTNM, ITU-T, IETF, etc.) and mobile network management standards (e.g. 3GPP 
Release 6 and Release 7). See annex E for a propose correspondence to 3GPP IRP specification. 

• Are not yet available from other specifications and that should be further elaborated possibly as part of NGN 
OSS specification documents or by other fora as required. 
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1 1 .2 NGN OSS Service Interfaces of the MPCM Service 
Interface Group 

The MPCM covers the area of service ordering (order intake) and self-management, for instance applicable to User 
profile management. 

The identification of the NGN OSS Service Interfaces related to the Market Product and Customer Management 
(MPCM) Service Interface Group is for further study. 

1 1 .3 NGN OSS Service Interfaces of the SM Service Interface 
Group 

The identification of the NGN OSS Service Interfaces related to the Service Management (SM) Service Interface Group 
is for further study. 

The Service Management (SM) supports the management of services from the point of view of the end-user, 

e.g. supporting SLA management. Service provisioning. Service Assurance and the link between the two, and Service 

composition, VPN / Connectivity, Service Profile management, etc. 

The SM focuses on the provisioning of the service elements of the NGN network infrastructure, on the assurance of 
NGN services end-to-end and on the billing of these services. 

1 1 .4 NGN OSS Service Interfaces of the SRM Service Interface 
Group 

The identification of the NGN OSS Service Interfaces related to the Service Resource Management (SRM) Service 
Interface Group is in the scope of Release 1 . 

The NGN OSS Service Interfaces for Service Resource Management shall focus on managing, with first priority, on 
real time conversational services (voice) and content delivery services (Video-on-Demand) across several sub-networks. 
This covers the management of the RACS, of the NASS, of the PES, of the Application Servers, of associated network 
capabilities (e.g.: localization, presence, reachability) and of the service access / end points (CPE equipment). 

As a summary, standardization effort on the NGN OSS Service Interfaces shall apply in the following functional areas: 

• Service Application Management. 

• Network Capability Management (Presence, Reachability, Localization). 

• CPE provisioning. 

• Self management (Profile Management). 

• Billing /rating configuration management. 

Further, generic management specifications defined for Resource Fault Management, Resource Test Management, 
Resource Performance Management, etc. according to the eTOM processes (see below) may need to be adapted. 

1 1 .5 NGN OSS Service Interfaces of the TRM Service Interface 
Group 

The identification of the NGN OSS Service Interfaces related to the Transport Resource Management (TRM) Service 
Interface Group is in the scope of Release 1 . 

The Transport Resource Management shall focus on managing provisioned/ connectivity services (e.g.: IP, VPN, VPLS, 
and other leased line data services and "pipes") including access points across several sub-networks. 
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For specific sub-networks, it may be possible to reuse existing management specifications. In particular, for transport 
network resource configuration purposes: 

• Management specification for managing mobile transport networks may be mapped onto 3GPP Network 
Resource Model (NRM) specifications. The corresponding NGN OSS Service Interfaces may have 
correspondence with 3GPP specifications. 

• Management specification for managing fixed transport networks may be mapped onto TMF MTNM 
specifications. The corresponding NGN OSS Service Interfaces may be mapped onto TMF MTNM Interface 
Model specifications. 

• Management specification for managing IP transport services may be mapped onto TMF IPNM specifications. 
The corresponding NGN OSS Service Interfaces may be mapped onto TMF IPNM Interface Model 
specifications. 

Areas of standardization in Transport Resource Management concern NGN network management, cross-domain 
Ethernet service management, IP address management, etc. Work should be done in cooperation with TMF 
MTNM/IPNM for fixed transport network management functions 

Standardization effort on the NGN OSS Service Interfaces shall apply in the following functional areas: 

• VoIP Management. 

• VoIP Traffic Management. 

• NGN Trunk and NGN Routing Management. 

• NGN Protocol Management e.g.: SIP, H248, .... 

Further, generic management specifications shall be defined for Resource Fault Management, Resource Test 
Management, Resource Performance Management, etc. according to the eTOM processes. These shall be mapped 
whenever possible onto existing 3GPP, TMF or ITU-T management specifications and Interface Models. 

1 1 .6 NGN OSS Service Interfaces of the SPM Service Interface 
Group 

The identification of the NGN OSS Service Interfaces related to the Supplier/Partner Management (SPM) Service 
Interface Group is for further study. 

1 1 .7 NGN OSS Service Interfaces of the BFS Service Interface 
Group 

The identification of the NGN OSS Service Interfaces related to the Basic Framework Services (BFS) Service Interface 
Group is in the scope of Release 1 . 

These NGN OSS Basic Framework Service Interfaces need to be further elaborated or mapped onto existing 
specifications if available in the framework of the NGN OSS Architecture: 

Communication Service Interfaces for each used Interaction Pattern. 

Publication / Registration Service Interfaces. 

Customization Service Interfaces. 

Security Service Interfaces. 

Etc. 
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Annex A (informative): 

Examples of Resource IVIanagement Functions 

Figure A. 1 may be used to illustrate the SRM Service Interface Groups s as well as possible information models and 
solutions sets. The boxes in the diagram are to be considered as examples of functions required for NGN management 
(in addition to the traditional FCAPS) and identify areas where new Sis shall be proposed as explained in clause 6. 
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Figure A.2 may be used to illustrate the TRM Functions as well as possible information models and solutions sets. 
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Annex B (informative): 

Summary of the rules of SIVI, SRIVI, TRIVI Service Interface 

Groups 

Table B.l summarizes the role of each Service Interface Groups. This is to help understand what those Service Interface 
Groups are designed for. 

Table B.1 : Summary of the rules of SM, SRM, TRM Service Interface Groups 
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Service Resource Management (SRM): Responsible for the management of : "] 


• The application 
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Subscriber data and user 
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Transport Resource Management (TRM) Responsible for the management of : | 
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Annex C (informative): 

NGN OSS Architecture metamodel 



It is generally considered "best practice" to underpin management architectures with a formal metamodel based up the 
use of a notation such as the Unified Modelling Language (UML). UML is designed in such a way that other more 
specialized languages may be developed from it. 

The benefits of architecture metamodels is that they lead to a precise specification of the architectural terms, entities and 
the relationships amongst them. This is particularly important for Service Oriented Architectures where these 
relationships are formed at run time rather than at design time and are not subject to validation by human architects. 

The TMF NGOSS Technology Neutral Architecture has a metamodel TMF 053, which is a specialization of the Object 
Management Group (OMG) UML L5, for NGOSS based architectures. These metamodels take a number of design 
iterations to get them correct, and usually require that functional, information, and deployment aspects have been 
considered. 

At this stage of development of the TISPAN NGN Management Architecture there is no experience with the 
deployment aspects so it is difficult to be absolutely confident that a metamodel of the NGN Management Architecture 
is complete, or accurate at this point in time. 

The metamodel is a formal UML definition of the architectural concepts outlined in clause 6. Its main value is that it 
specifies the relationships between the architectural entities and their cardinality. It is expected that practical use in 
TISPAN of the metamodel to define extensions to the 3GPP IRPs, and liaison activities with both the TMF and 3GPP, 
will allow us to make this a normative annex in a later version. 

This architecture metamodel shall be based on: 

• service oriented architecture principles, such as those from Web Services; 

• use of TMF NGOSS TMF NGOSS metamodel TMF 053 and contract TMF 053 as a pragmatic definition of an 
SOA for OSS architectures; 

• re-use of 3GPP specifications 

• alignment with TMF MTNM/MTOSI (TMF 513 [17], TMF 608 [13], TMF 814 [18]) specifications. 

The alignment with NGOSS as the SOA and the alignment with IRPs are considered of equal importance. This is due to 
the fact that the NGOSS SOA is considered to have a rigorous metamodel; and without a metamodel there is greater 
difficulty in achieving an implementable system. 

The remainder of this annex reviews the main characteristics of these inputs before proposing the NGN OSS 
Architecture metamodel. 



C.1 Service Oriented Architecture 

There is not single industry definition of Service Oriented Architecture (SOA) but several sources have similar 
definitions: 

• http://www.service-architecture.com/ ; 

• http://www-306.ibm.com/software/solutions/webservices/ . 

SOAs are characterized by (logical) components that expose service interfaces to other components. These service 
interfaces specify the operations that may be exposed to other components. 

All invocation relationships between components are established dynamically at run time using a locate-bind-execute 
model. This means: 

• there is no static reference point architecture; 

• a run time mechanism: a registry repository is needed to support the locate-bind-execute model; 
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• the registry/repository needs to be structured so that components can search for, and find, the services that they 
wish to use. 

One of the characteristics of a SOA is that a component may be used by any other component subject only to the other 
component having the necessary security access rights, and the ability to comply with the signature of the component 
service interface. 

A specific issue with SOA Architecture and Design (SOAD) is the level of granularity of the definition of these 
services. Typically these are more granular than the operations that one would find in a OO Analysis and Design 
(OOAD). However both SOAD and OOAD use UML as the basis of their specifications. 

As an example, a Service Interface might be "Customer Profiling" whereas a typical Operation might be "List 
customers by name and postal code", ( http://www-128.ibm.com/developerworks/webservices/librarv/ws-soadl/ ). 



C.2 Anatomy of Web Services 



Web services using Web Service Description Language (WSDL) have a concept of separating the logical from the 
physical aspects of an API by providing an Abstract (specification) API that is realized by a Concrete (implementation) 
API. Many of the terms are derived from software practice rather than Telecom. Specifically the term "interface" is used 
differently from TMN or common telecoms usage. Interfaces are logical and specify what needs to be implemented and 
may be realized by one or more software implementations. 

• abstract (specification) API in Web Services based on WSDL comprise: 

interfaces which represent service interfaces and can comprise one or more Operations; 
operations representing Web service functions and can contain multiple Messages; 
messages represent collections of input and output parameters which may be grouped into parts; 
parts which represent Operation parameter data. 

• concrete APIs comprise of the following additional elements: 

service elements that represent collections of Endpoints; 

endpoints that contain Endpoint data including: physical addresses and protocol information; 

binding elements associate themselves to Operations elements; 

Each Endpoint references a Binding element, and thus relates the Endpoint information to an underlying 
Operation. 

C.3 NGOSS Architecture IVIetamodel 

NGOSS is essentially an SOA model. Figure C. 1 consists of the following NGOSS entities (shown in Yellow). 

NGOSS Extensible Element. This provides the core modelling entity for NGOSS and is derived from the UML 1.5 
concept of a ModelElement and a GeneralizableElement. It provides the key attributes and relationships which should 
be supported by all derived NGOSS extensible elements. 

NGOSS Component is a software entity that can be independently deployed (unit of deployment) and built conforming 
to a component software model, and uses NGOSS Contracts to expose its functionality. 

NGOSS Shared information Entities is a super-class for defining all information that can be shared and reused amongst 
different NGOSS Components. 

NGOSS Contract. This is the core NGOSS concept and this captures the atomic level of functionality. It captures the 
relationship with the Shared information Entities that it "uses"; and it provides the element of functionality "exposed 
by" the NGOSS component that it supports. 

NGOSS Components are logical grouping of contracts and are logical "Units of Deployment" for Services. 
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Figure C.I : Core NGOSS architecture metamodel and relationshiip to UIVIL v1.5 metamodel 



C.4 Anatomy of TMF MTOSI 



MTOSI is a extension of the TMF MTNM management interface for telecommunication networking technology. 
MTNM is currently based on CORBA Platform and covers ATM, SDH, DSL, Ethernet and Control Plane technologies. 

The main MTOSI extension is to provide XML messages and message exchange patterns that can be operated over 
either a Java Messaging Service (SOAP over JMS) or HTTP Web Service platform. The contents of these messages 
reference the MTNM Information Model (TMF 608 [13]). The operations are based on MTNM, but have been extended 
to be document oriented, and support both efficient inventory and fault management requirements. 

MTOSI has adopted the concept of a separate Abstract and Concrete API and has two additional standardization 
concepts: 

• Communication Patterns (also known in Web Services as Message Exchange Patterns) based on software 
industry practice. 

• Communication Styles to accommodate both Remote Procedure and Messaging styles of Software platform 
implementation. These allow relatively simple binding to be produced to current technologies: JMS and HTTP 
Web Services; and provide the mechanism to move to new technologies e.g. WSDL 2.0. 



C.5 3GPP Architecture and metamodels 

This clause analyses the current 3GPP documents that have a relationship with the proposed TISPAN NGN 
Management metamodel. 

The key sources of models in 3GPP are: 

• TS 132 150 [4] Integration Reference Point (IRP) Concept and definitions; 
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TS 132 151 [5] Integration Reference Point (IRP) IS template; 

TS 132 312 [8] Generic Integration Reference Point Information Service; 

TS 132 152 [6] Integration Reference Point (IRP) Information Service Unified Modelling Language 
repertoire; 

TS 1 32 622 [2 1 ] Generic NRM IRP IS ; 

TS 132.632 [22] CN NRM IRP IS (including IMS model). 

The primary focus in 3GPP S A5 is the definition of Itf-N between Network Managers (NM) and either Element 
Managers (EM) or Network Elements (NE). 



IRPManager 



NM 



IRP Agent 



Itf-N 




NEs 



EM 



Supported IRP(s) 



Figure C.2: Example of 3GPP System Context 

Note that the physical interface supports the relationship between and IRP Manager and IRP Agent. The IRP Agent 
supports a set of IRPs i.e. Interface IRPs (e.g. Alarm IRP [15]), Network Resource Model IRPs (e.g. CN NRM IRP), 
Data Definition IRPs (e.g. State Management IRP). 

3GPP does not have currently a formal metamodel. It does however have some of these concepts captured in the UML 
stereotypes that it defines e.g. «InformationObjectClass», «Interface». In TS 132 150 annex C [4] Integration 
Reference Point (IRP) Concept and definitions, an informative example is given. 



£75/ 



40 



ETSI TS 188 001 VI. 1.1 (2005-09) 



Generic NRM 



«lnformationObjectClass» 

Top 



<}- 



- objectClass 



1\ 



BasicCmIRP IS 



«lnformationObiectClass» 

BasicCmIRP 



«InformationObjectClass» 

IRPAgent 



- systemDN 



\y# isContainecJIn 
IRPAgerit-GenericIRP 
#contains Q.A 



«InfonnationObjectClass» 



■IRPId 



^^ 



<^ 



0..I 



Inheritance 



AlarmlRP IS 



«InfonTiationObjectClass» 

AlarmlRP 



Figure C.3: Example of possible packages together with Information Object Classes (lOCs) 

and their inter-relationships 

NOTE 1: This diagram is taken from an informative annex of TS 132 150 (V6.2.0). 
There are a few very important modelling points in figure C.3: 

• IRP IS are collections of UML specifications and accompanying definitions; 

• ManagedGenericIRP InformationObjectClass, which inherits from GenericlRP, is the super-class for all 
Interface IRPs; 

• IRP Agents are a container for the IRPs exposed over Itf-N. 

• Top is the superclass for all 3GPP IRP InformationObjectClasses. 
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Figure C.4: Managed generic IRP derived from Generic IRP 
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Figure C.5: Operations and notifications for IVIanaged Generic IRP 

Example of IRPs are the Alarm IRP which performs much the same function as the NGOSS Component in that it is a 
unit of deployment, albeit contained within a IRP Agent. Its operations, i.e. getAlarmList in Alarm IRP, seem to line up 
with the NGOSS Contract concept. 

In 3GPP different kinds of solutions sets can be derived from the IRPs. Specifically mappings to CORB A, CMIP and 
XML. 

NOTE 2: XML specifications are not SSs but parts of SSs have been created. These are conceptually equivalent to 
the concrete API binding described for Web Services and MTOSI above. Theses reaUzations are called 
IRP Solution Sets (SS). 



C.6 TISPAN NGN Management metamodel 

The approach adopted by TISPAN is to create a metamodel, using UML, of the concepts introduced in the main body of 
the document. 

The NGN OSS Architecture reuses and generalizes concepts from UML/Java/C# (class, interface, component), 3GPP 
IRP methodology (Information Service), and TMF NGOSS DIOA (interface, contract, server component, client 
component) to define a novel, component-based and service-oriented approach to telecom management. The 
architecture is defined by a UML metamodel that is depicted and explained below. 

NOTE 1: This annex refers to concepts from OMG UML 2.0, 3GPP IRP, and TM Forum NGOSS. These concepts 
are defined and explained in the following references: 

• "UML Distilled - Third Edidon" by Martin Fowler, ISBN 0-321-19368-7. 

• "The UML User Guide - Second Edition" by Grady Booch, James Rumbaugh, 
Ivar Jacobson, ISBN 0-321-26797-4. 

• 3GPP SA5 TS 32-series on IRPs. 
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• "The NGOSS Technology-Neutral Architecture (TNA)", TMF053. 

• "NGOSS TNA Contract Description: Business and System Views", TMF053B. 



• "NGOSS TNA Metamodel", TMF053D. 

NOTE 2: It is expected that the planned harmonization activities will lead to some adjustment of this metamodel 
and the mapping in the next release, version 2. 

NOTE 3: The fundamental starting point of the NGN OSS Architecture is interface orientation but it goes far 

beyond by defining component-based and service-oriented approaches as well. The interface concept is 
taken from UML/Java/C#. Interfaces group operations and constant data and may be exposed by different 
types of entities such as class instances, components, or services. 

NOTE 4: SOA introduces two views on components and services: the inward view of a service consumer/ 

requester, who requires interfaces (depicted as sockets/crescents), and the outward view of a service 
provider, who provides interfaces (depicted as balls/lollipops). 

Figure C.6 shows the TISPAN metamodel in UML Notation. 
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Figure C.6: TISPAN NGN OSS Architecture metamodel 

This diagram is the formal metamodel in UML for the definitions in clause 3 and the reference model in clause 6. The 
key value that this metamodel adds is the relationships amongst architectural entities and their cardinality. 

The definitions of these terms are exactly as described in the Definitions clause 3. 
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C.7 Mapping of TISPAN Management Architecture to 
3GPP, NGOSS 

TISPAN specifications that realise this architecture have to be aligned with 3GPP and TMF NGOSS amongst others, 
and to assist this alignment a mapping of the TISPAN terms and concepts to the current terms in used by these other 
groups has been produced. 

The following table provides the current understanding of the mapping of TISPAN terms to these other architectures. 





ETSI TISPAN NGN OSS 
(TS 188 001) 


3GPP SA5 IRP 
(TS 32-series) 


TM Forum NGOSS 

TNA 
(TMF 053-series) 


OMG UML 2.0 


unit of 
deployment 


for further study 


- 


NGOSS Component 


Component 


ellipse 


atomic and composite NGN OSS Service 


Operations 
Systems 
Function (OSF) 
(as implemented 
by one or more i/f 
IRP IOCS which 
expose only 
lollipops) 




Classifier 


lollipop 


NGN OSS Service Interface (NGN OSS 
SI) 


one or more 
i/f IRP IS 
«lnterface»s 


NGOSS Contract 


provided Interface 
(see note 1) 


operation 


NGN OSS Operation 


Operation 


NGOSS Contract 
Operation 


Operation 


notification 


NOTE - Mapping of notifications to 
TISPAN NGN OSS Operations is for 
further study. 


Notification 






ellipse 
with only 
crescents 
(consumer 
role) 


NGN OSS Service with only NGN OSS 
SICs 


IRPIVIanager 


client entity 


Classifier with 
only required 
Interfaces 


crescent 


NGN OSS Service Interface Consumer 
(NGN OSS SIC) 




client entity Contract 
(see note 2) 


required Interface 
(see note 3) 


ellipse 
with only 
lollipops 
(provider 
role) 


NGN OSS Service with only NGN OSS 
Sis 


IRPAgent 


server entity 


Classifier with 
only provided 
Interfaces 


dotted line 
ovale 


NGN OSS Service Interface Groups 
primarily based on M.3050 








NOTE 1 : Qualification by "provided" is for further study. 
NOTE 2: Possibly to be added to the NGOSS meta-model. 
NOTE 3: Qualification by 'required' is for further study. 



NOTE 1: Mapping of 3GPP Notifications to TISPAN NGN OSS Operations is for further study. 
A few important points to note are: 

• All groups have the same concept of an Operation. 

• NGOSS introduces the concept of a Logical Component which seems to be equivalent to the more general term 
Service as adopted by the SOA community. 

• NGOSS introduces concepts around the use of policy. 

NOTE 2: The concepts of lifecycle and methodology and their impact on architecture artifacts are for further study. 
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Annex D (informative): 

Re-use of 3GPP IRPs for NGN OSS Release 1 

The focus of NGN OSS Release 1 is on the Resource Management Service Interfaces covering both Service Resources 
Management and Transport Resources Management. 

ETSI NGN OSS should as a priority re-use 3GPP IRPs. 



D.1 3GPP Documents 



The following clause identifies candidate 3GPP documents: 

1 Feature: Charging Management (CH) 
TS 32.295 Charging Data Record (CDR) transfer 

TS 32.296 Online Charging System (OCS): Applications and interfaces 
TS 32.297 Charging Data Record (CDR) file format and transfer 
TS 32.298 Charging Data Record (CDR) parameter description 
TR 32.815 Online Charging System (OCS) architecture study 

BB: Bearer Charging (CH-BC) 

TS 32.240 Charging architecture and principles 

TS 32.250 Circuit Switched (CS) domain charging 

TS 32.251 Packet Switched (PS) domain charging 

TS 32.252 Wireless Local Area Network (WLAN) charging 

BB: IMS Charging (CH-IC, IMS2-CH) 

TS 32.260 IP Multimedia Subsystem (IMS) charging 

TS 32.299 Diameter charging applications 

BB: Service Charging (CH-SC, MMS6-CH, LCS-CH, PoC-CH, MBMS-CH) 

TS 32.270 Multimedia Messaging Service (MMS) charging 

TS 32.271 Location Services (LCS) charging 

TS 32.272 Push-to-talk over Cellular (PoC) charging 

TS 32.273 Multimedia Broadcast and Multicast Service (MBMS) charging 

2 Feature: Subscription Management (SuM) 
TS 32.140 Subscription Management (SuM) requirements 
TS 32.141 Subscription Management (SuM) architecture 

TS 32.171 Subscription Management (SuM) NRM IRP: Requirements 
TS 32.172 Subscription Management (SuM) NRM IRP: Information Service 
TS 32.175 Subscription Management (SuM) NRM IRP: XML definition 
TR 32.803 Process guide; Use cases in Unified Modelling Language (UML) 
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Feature: OAM&P (Operations, Administration, Maintenance & Provisioning) - (OAM) 

3.1 BB: Principles, liigli level Requirements & Architecture (OAM-AR) 

TS 32.101 Telecommunication management; Principles and high level requirements 
TS 32.102 Telecommunication management; Architecture 

3.2 BB: Performance Management (OAM-PM) 

TS 32.401 Performance Management (PM); Concept and requirements 

TS 52.402 Performance Management (PM); Performance measurements - GSM 

TS 32.403 Performance Management (PM); Performance measurements - UMTS and combined UMTS/GSM 

TS 32.411 Performance Management (PM) IRP: Requirements 

TS 32.412 Performance Management (PM) IRP: Information Service 

TS 32.413 Performance Management (PM) IRP: CORBA SS 

TS 32.414 Performance Management (PM) IRP: CMIP SS 

TS 32.431 Performance measurement collection IRP; Requirements 

TS 32.432 Performance measurement: File format definition 

TS 32.435 Performance measurement: XML file format definition 

TS 32.436 Performance measurement: ASN. 1 file format definition 

3.3 BB: Subscriber and Equipment Trace Management (OAM-Trace) 
TS 52.008 GSM subscriber and equipment trace 

TS 32.421 Subscriber and equipment trace; Trace concepts and requirements 

TS 32.422 Subscriber and equipment trace; Trace control and configuration management 

TS 32.423 Subscriber and equipment trace; Trace data definition and management 

3.4 BB: Network Infrastructure Management (OAM-NIM) 
TS 32.150 IRP Concept and definitions 

TS 32.151 IRP Information Service template 

TS 32.152 IRP Information Service Unified Modelling Language (UML) repertoire 

TR 32.805 Process guide; Backward compatibility recommendations 

TS 32.300 Configuration Management (CM); Name convention for Managed Objects 
TS 32.600 Configuration Management (CM); Concept and high-level requirements 

Fault Management including Alarm IRP 

TS 32.111-1 Fault Management; Part 1 : 3G fault management requirements 
TS 32.111-2 Fault Management; Part 2: Alarm IRP: Information Service 
TS 32.111-3 Fault Management; Part 3: Alarm IRP: CORBA SS 
TS 32.111-4 Fault Management; Part 4: Alarm IRP: CMIP SS 
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TS 32.111-5 Fault Management; Part 5: Alarm IRP: XML definitions 

Notification IRP 

TS 32.301 Configuration Management (CM); Notification IRP: Requirements 

TS 32.302 Configuration Management (CM); Notification IRP: Information Service 

TS 32.303 Configuration Management (CM); Notification IRP: CORBA SS 

TS 32.304 Configuration Management (CM); Notification IRP: CMIP SS 

TS 32.305 Configuration Management (CM); Notification IRP: CMIP SS 

Generic IRP management 

TS 32.311 Generic IRP management; Requirements 
TS 32.312 Generic IRP management; Information Service 
TS 32.313 Generic IRP management; CORBA SS 
TS 32.314 Generic IRP management; CMIP SS 

Test management IRP 

TS 32.321 Test management IRP: Requirements 
TS 32.322 Test management IRP: Information Service 
TS 32.323 Test management IRP: CORBA SS 
TS 32.324 Test management IRP: CMIP SS 

Notification Log IRP 

TS 32.331 Notification Log (NL) IRP: Requirements 

TS 32.332 Notification Log (NL) (NL) IRP: Information Service 

TS 32.333 Notification Log (NL) IRP: CORBA SS 

TS 32.334 Notification Log (NL) IRP: CMIP SS 

TS 32.335 Notification Log (NL) IRP: XML solution definitions 

File Transfer IRP 

TS 32.341 File Transfer (FT) IRP: Requirements 
TS 32.342 File Transfer (FT) IRP: Information Service 
TS 32.343 File Transfer (FT) IRP: CORBA SS 
TS 32.344 File Transfer (FT) IRP: CMIP SS 
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Communication Surveillance IRP 

TS 32.351 Communication Surveillance (CS) IRP: Requirements 
TS 32.352 Communication Surveillance (CS) IRP: Information Service 
TS 32.353 Communication Surveillance (CS) IRP: CORBA SS 
TS 32.354 Communication Surveillance (CS) IRP: CMIP SS 

Entry Point IRP 

TS 32.361 Entry Point (EP) IRP: Requirements 

TS 32.362 Entry Point (EP) IRP: Information Service 

TS 32.363 Enti-y Point (EP) IRP: CORBA SS 

Security Management IRP 

TS 32.371 Security Management concept and requirements 

Basic CM IRP 

TS 32.601 Configuration Management (CM); Basic CM IRP; Requirements 
TS 32.602 Configuration Management (CM); Basic CM IRP: Information Service 
TS 32.603 Configuration Management (CM); Basic CM IRP: CORBA SS 
TS 32.604 Configuration Management (CM); Basic CM IRP CMIP SS 

Bulk CM IRP 

TS 32.611 Configuration Management (CM); Bulk CM IRP: Requirements 

TS 32.612 Configuration Management (CM); Bulk CM IRP: Information Service 

TS 32.613 Configuration Management (CM); Bulk CM IRP: CORBA SS 

TS 32.614 Configuration Management (CM); Bulk CM IRP: CMIP SS 

TS 32.615 Configuration Management (CM); Bulk CM IRP: XML file format definition 

Generic NRM IRP 

TS 32.621 Configuration Management (CM); Generic network resources IRP; Requirements 

TS 32.622 Configuration Management (CM); Generic network resources IRP: NRM 

TS 32.623 Configuration Management (CM); Generic network resources IRP: CORBA SS 

TS 32.624 Configuration Management (CM); Generic network resources: IRP: CMIP SS 

TS 32.625 Configuration Management (CM); Generic network resources IRP: Bulk CM XML file format 
definition 
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CN NRM IRP 

TS 32.631 Configuration Management (CM); Core network resources IRP: Requirements 

TS 32.632 Configuration Management (CM); Core Network Resources IRP: NRM 

TS 32.633 Configuration Management (CM); Core network resources IRP: CORE A SS 

TS 32.634 Configuration Management (CM); Core network resources IRP: CMIP SS 

TS 32.635 Configuration Management (CM); Core network resources IRP: Bulk CM XML file format 
definition 

UTRAN NRM IRP 

TS 32.641 Configuration Management (CM); UTRAN network resources IRP; Requirements 

TS 32.642 Configuration Management (CM); UTRAN network resources IRP: NRM 

TS 32.643 Configuration Management (CM); UTRAN network resources IRP: CORE A SS 

TS 32.644 Configuration Management (CM); UTRAN network resources IRP: CMIP SS 

TS 32.645 Configuration Management (CM); UTRAN network resources IRP: Bulk CM XML file format 
definition 

GERAN NRM IRP 

TS 32.651 Configuration Management (CM); GERAN network resources IRP: Requirements 

TS 32.652 Configuration Management (CM); GERAN network resources IRP: NRM 

TS 32.653 Configuration Management (CM); GERAN network resources IRP: CORE A SS 

TS 32.654 Configuration Management (CM); GERAN network resources IRP: CMIP SS 

TS 32.655 Configuration Management (CM); GERAN network resources IRP: Bulk CM XML file format 
definition 

Kernel CM IRP 

TS 32.661 Configuration Management (CM); Kernel CM; Requirements 
TS 32.662 Configuration Management (CM); Kernel CM; Information service 
TS 32.663 Configuration Management (CM); Kernel CM IRP: CORBA SS 
TS 32.664 Configuration Management (CM); Kernel CM IRP: CMIP SS 

State Management IRP 

TS 32.671 Configuration Management (CM); State Management IRP: Requirements 

TS 32.672 Configuration Management (CM); State Management IRP: Information Service 

TS 32.673 Configuration Management (CM); State Management IRP: CORBA SS 

TS 32.674 Configuration Management (CM); State Management IRP: CMIP SS 

TS 32.675 Configuration Management (CM); State Management IRP: Bulk CM XML file format definition 
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Inventory Management IRP 

TS 32.690 Inventory Management (IM): Requirements 

TS 32.691 Inventory Management (IM) network resources IRP: Requirements 

TS 32.692 Inventory Management (IM) network resources IRP: NRM 

TS 32.695 Inventory Management (IM) network resources IRP: Bulk Configuration Management (CM) XML 
file format definition 

Transport Network NRM IRP 

TS 32.711 Configuration Management (CM); Transport Network (TN) NRM IRP: Requirements 

TS 32.712 Configuration Management (CM); Transport Network (TN) NRM IRP: Information Service 

TS 32.713 Configuration Management (CM); Transport Network (TN) NRM IRP: CORBA SS 

TS 32.714 Configuration Management (CM); Transport Network (TN) NRM IRP: CMIP SS 

TS 32.715 Configuration Management (CM) Transport Network (TN) NRM IRP: Bulk CM XML file format 
definition 



Signalling Transport Network interface NRM IRP 

TS 32.741 Configuration Management (CM); Signalling Transport Network (STN) interface NRM IRP: 
Requirements 

TS 32.742 Configuration Management (CM); Signalling Transport Network (STN) interface NRM IRP: 
Information Service 

TS 32.743 Configuration Management (CM); Signalling Transport Network (STN) interface NRM IRP: 
CORBA SS 

TS 32.744 Configuration Management (CM); Signalling Transport Network (STN) interface NRM IRP: 
CMIP SS 

TS 32.745 Configuration Management (CM); Signalling Transport Network (STN) interface NRM IRP: Bulk 
CM XML file format definition 



D.2 NGN OSS Service Interfaces 

D.2.1 NGN OSS Service Interfaces to standardize 

The standardization work on Service Interfaces could be classified as follows: 

• Network Resource Model (NRM) Information Services for the NGN network nodes of the ETSI NGN 
architecture not yet covered by: 

a) 3GPP IRPs should be proposed to be included the 3GPP Release 7 specification set; 

b) TMF (e.g. MTNM, IPNM, MTOSI, etc.) a proposal of related Information Services should be made 
by ETSI TISPAN to be included as part of MTOSI, in such a way that Information Services 
provide a homogeneous views on the fixed/mobile converged network; 
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c) other possible NRM IRP Information Services should be specified by ETSI TISPAN. 

Resource Management (RM) Information Services supporting the management of the Service and Transport 
Resources in the network: 

d) possible areas of work in Service Resource Management concern adaptation of the 3GPP 
subscription management IRP to ETSI TISPAN requirements, applications management SI, CPE 
management SI, etc.; 

e) possible areas of work in Transport Resource Management concern NGN network management 
Information Services, cross-domain Ethernet service management Information Services, VoIP 
management SI, IP address management SI, etc. Work should be done in cooperation with TMF 
MTNM/IPNM for fixed transport network management functions. 

• Service Management (SM) Sis, supporting the management of services from the point of view of the 
end-user, e.g. supporting SLA management. Areas of work concern. Service provisioning SI, Service 
Assurance SI and the link between the two, and Service composition SI, VPN/Connectivity SI, Service Profile 
management SI, etc.; 

• Market Product and Customer (MP&C) Sis cover the area of service ordering and self management. Possible 
areas of work are Order intake SI, User profile management SI, etc.; 

• another area of work concerns security management Sis starting from the different available security 
architectures (TMF, 3GPP, ITU-T, etc.). 

D.2.2 NGN Network Resource Model (NRM) 

ETSI TISPAN should rely on the Network Resource Model (NRM) IRPs from 3GPP for the mobile network technology 
management aspects and on the MTNM model for the fixed network technology management aspects. For the latter, it 
is assumed that only Sis at Transport Resource Management level need to be identified and that these should be part of 
MTOSI. 

ETSI TISPAN should work on the aUgnment of the following 3GPP Resource IRPs with MTNM and IPNM to obtain 
common Sis for the ETSI NGN OSS TRM Service Interface Group: 

TS 132 711 Transport Network (TN) Network Resource Model (NRM). 

TS 132 63 1 Configuration Management (CM) Core network resources. 

TS 32.731 Service Specific Core Network (CN) IMS Network Resource Model (NRM). 

NEW: Wireless and Wireline BB Access (BBA) Network Resource Model (NRM). 

NEW: Mobile 3G Network Resource Model SI (planned as part of MTOSI Phase 2) i.e. giving an abstract 
view on Mobile NRM. 

ETSI TISPAN should elaborate the following Resource Sis in cooperation with 3GPP and MTNM/IPNM: 

• NEW: NGN (NGN) Network Resource Model (NRM) for softswitches, gateways, application servers, etc. 

• NEW: Service Infrastructure Network Resource Model (NRM) for application servers, content servers, etc. 

• NEW: CPE Network Resource Model (NRM) for CPE management. 

D.2.3 NGN Transport and Service Resource Service Interfaces 

Service provisioning should be done partly via OSSs to configure the supporting network resources (provisioned 
services) and partly will be user initiated signalled services which requires the pre-configuration of service transport 
infrastructure. Information about active services should be collected by the managers for assurance purposes. 

Additionally, subscriber and profile management are main OSS features, as multiple services will be requested by a 
single subscriber in the same contract (i.e. triple play - voice, video and internet). 
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In complement to existing work on network oriented Sis, the above requirements lead to the need for the Sis that will be 
necessary for managing new NGN services and NGN architecture. 

D.2.3.1 The Transport Resource Management Service Interfaces 

The NGN OSS Transport Resource Management Sis specifications should focus on managing provisioned/connectivity 
services including access points across several sub-networks. Such specifications should 
re-use/extend/ contribute to3GPP IRPs and TMF specifications in the following functional areas: 

Cross-domain Transport Fault/ Alarm management; 

Cross-domain Transport Service Inventory Management; 

Cross-domain Transport Service Resource provisioning; 

Transport and Subscriber Line provisioning; 

Cross-domain Transport Service Performance and Traffic management; 

Security. 

It is foreseen that Sis will be defined in the following functional areas: 

VoIP Management; 

VoIP Traffic Management; 

NGN Trunk Management; 

NGN Routing Management; 

NGN Protocol Management (H.248/SIP/H.323). 

D.2.3.2 The Service Resource Management Service Interfaces 

The NGN OSS Service Resource Management Sis should focus on managing signalled services across several 
sub-networks. This includes also the management of the service applications, associated network capabilities 
(e.g. localization, presence, reachability) and the service access/end points (CPE equipment). 

The NGN OSS Service Resource Management Sis should extend 3GPP IRPs in the following functional areas: 

• Service Fault/Alarm Management; 

• Service Test Management; 

• Service Inventory Management; 

• Service Resource provisioning; 

• Service and Subscriber Data provisioning; 

• Service Performance management; 

• Security. 

It is foreseen that Sis will be defined in the following functional areas: 

• Service Application Management; 

• Network Capability Management (Presence, Reachability, Localization); 

• CPE provisioning; 

• Self management (Profile Management); 
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• Billing /rating configuration management. 

D.2.4 NGN Release 1 Service Interface Priorities 

For NGN Release 1, it has been decided to focus the standardization effort on the Service and Resource Management 
Service Interface Groups and related Sis in order to support the requirements identified in TISPAN Requirement and 
Priorities for the management of: 

1) the IMS core and the PES ( PSTN/ISDN Emulation), including the related NASS and RACS aspects; 

2) the following services: 

Real time conversational services (voice) for both IMS like and PES like subscribers; 
Content delivery services (Video-on Demand). 

3) the following network capabilities (seen as components of above-mentioned services): 

nomadism; 

number, naming and addressing that enable NGN to uniquely identify each user; 

authentication of user at the access network. 

4) supporting the following operational processes: 

inventory; 

Service Configuration and Activation process of the SM&O; 
Resource provisioning of the RM&O. 
NGN performance, testing, assurance, QoS, etc. are to be covered in later releases. 
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Annex E (informative): 
Implementation View 

The Implementation View of the NGN OSS Architecture is for further study. 
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